The following definitions are introduced for the purpose of clarity.
AAA Authentication, Authorization and Accounting: AAA is a common name for both RADIUS and DIAMETER, i.e. solutions providing customer care, control and billing in a large IP network.
DIAMETER: A successor of RADIUS with increased security and scalability features compared to its predecessor RADIUS. It is currently under standardization by the IETF.
DHCP: Dynamic Host Configuration Protocol. DHCP is an Internet Engineering Task Force (IETF) standard for allocating Internet Protocol addresses and other configuration information to User Systems. User Systems can either be Fixed Hosts or Mobile Hosts. The allocation is done each time when the User System is started. A DHCP server allocates the information, which is then transferred to a DHCP client. An Internet Service Provider or an IT-department controls the DHCP server. The DHCP client is a SW functionality embedded in the User System.
DMZ: De-Militarized Zone is a zone between the Internet Service Provider router and Corporate firewall where access is allowed from both the Internet and the Intranet. Normally a subset of the services available on the Intranet is mirrored on the DMZ.
FA: Foreign Agent. The primary responsibility of an FA is to act as a tunnel agent which establishes a tunnel to a HA on behalf of a mobile node in a mobile IP environment.
HA: Home Agent. The primary responsibility of the HA is to act as a tunnel agent which terminates the mobile IP tunnel, and which encapsulates datagrams to be sent to the Mobile Node in mobile IP.
IETF: Internet Engineering Task Force. The IETF is the standardization organization for the Internet community.
IP: Internet Protocol. IP is a network layer protocol according to the ISO protocol layering. IP is the major end-to-end protocol between Mobile and Fixed End-Systems for Data Communications.
MANET: Mobile Ad hoc Networks. MANET is a common name for a family of protocols that provide multi-hop routing in highly dynamic mobile environments.
MIP: Mobile IP. MIP is an IP mobility standard being defined by the IETF with the purpose to make IP networks mobility aware, i.e. providing IP entities knowledge on where a Mobile Node is attached to the network. The standard includes the definition of a Foreign Agent and a Home Agent.
MN: Mobile Node. The MN comprises both the Terminal Equipment (TE) and the Mobile Termination (MT).
VLAN: Virtual Local Area Network. VLAN is a separation of a physical Local Area Network into a set of logical subnets.
VPN: Virtual Private Network. VPN is a secure overlay network on a common public infrastructure that allows a corporation to maintain its own addressing and routing between its sites and to remote users.
WLAN: Wireless Local Area Network. WLAN is a local area solution for radio access mobility for Mobile Nodes.
The business communication process consisting of suppliers, customers and partners are getting more and more interlaced. Even if business-to-business communication is in the midst of its hype, and the reality may not be as glamorous as first described, the needs for such solutions will remain. Extranets will play an important role of customer relationship management in the future.
However, as the security consciousness increase in organizations, it is not satisfactorily to just tie two or more companies together into an extranet. One would like to form workgroups within this extranet in order to create smaller zones-of-trust, allowing only a set of people to have access to a set of resources. This development has got increased focus as studies, such as the 2000 CSI-FBI Computer Crime and Security Survey, indicate that more than 70% of all unauthorized access to confidential information is made from the inside (i.e. not from the Internet). These types of computer crimes are by far the most expensive of all computer crimes within an enterprise.
There are essentially two network types where one can include support for extranet solutions. One is in the virtual private network that connects sites together and the other is in the campus networks of each site. The current best practice for both these network types are explained in the following chapter.
Several solutions have been put forward to achieve different levels of network privacy when building VPNs across a shared IP backbone, so target network-based VPNs. Most of these solutions require separate per VPN forwarding capabilities and make use of IP or MPLS based tunnels across the backbone network. The state of the art when it comes to providing extranets in network-based VPNs is to deploy of a set of virtual routers (VRs) in one physical router. In this sense both intranet and extranet VPNs can be deployed, each using a separate virtual router. The objective is to provide per VPN based routing, forwarding, quality of service, and service management capabilities. The virtual router concept deploys exactly the same mechanisms as a physical router, and therefore inherits all existing mechanisms and tools for configuration, deployment, operation, troubleshooting, monitoring, and accounting. Virtual routers can be deployed in different VPN configurations, direct VR to VR connectivity through layer-2 links/tunnels or by aggregating multiple VRs into a single VR combined with IP or MPLS based tunnels. This architecture accommodates different backbone deployment scenarios, e.g. where the VPN service provider owns the backbone, but also where the VPN service provider obtains backbone service from one or more other service providers.
Within a VPN domain, an instance of routing is used to distribute VPN reachability information among VR routers. Any routing protocol can be used, and no VPN-related modifications or extensions are needed to the routing protocol for achieving VPN reachability. VPN reachability information to and from customer sites can be dynamically learned from the customer equipment using standard routing protocols or it can be statically provisioned on the VR. The routing protocol between the virtual routers and customer equipments is independent of the routing used in the VPN backbone. Furthermore, the routing protocol between the VRs may be the same or it might be different than the routing mechanism used between the customer equipment and the VR.
There are two fundamental architectures for implementing network based VPNs. Those are virtual routers (VR) and piggybacking. The main difference between the two architectures resides in the model used to achieve VPN reachability and membership functions. In the VR model, each VR in the VPN domain is running an instance of a routing protocol responsible to disseminate VPN reachability information between VRs. Therefore, VPN membership and VPN reachability are treated as separate functions, and separate mechanisms are used to implement these functions. VPN reachability is carried out by a per-VPN instance of routing, and a range of mechanisms is possible for determining membership. In the piggyback model the VPN network layer is terminated at the edge of the backbone, and a backbone routing protocol (i.e. BGP-4) is responsible for disseminating the VPN membership and reachability information between provider edge routers (PE) for all the VPNs configured on the PE.
Extranets are commonly used to refer to a scenario whereby two or more companies have network access to a limited amount of each other's corporate data. An important feature of extranets is the control of who can access what data, and this is essentially a policy decision. Policy decisions are enforced at the interconnection points between different domains. The enforcement may be done via a firewall, router with access list functionality, or any device capable of applying policy decision to transit traffic.
In the VR architecture, policy is enforced between two VPNs, or between a VPN and the Internet, in the same manner as is done today without VPNs. For example, two VRs (VPNs) could be interconnected. Each VR locally imposes its own policy controls via a firewall on all traffic that enters its VPN from the outside (whether from another VR or from the Internet). Combining firewalls and exchanging private routes between VRs (members of different VPNs) provide a mechanism to build different flavors of extranets. However, this network-based VPN model has some drawbacks or flaws:                a Corporations normally apply private address realms in the VPNs, and creating an extranet VPN by tying together two existing VRs, would then create address collisions. Therefore, in this model, each new extranet normally a new set of virtual routers with a separate address realm from any of the intranet VPNs has to be created. This does not only mean an exponential increase in the number of virtual routers, but also that the end stations are required to be associated with at least one IP address for every VPN (intranet and extranet) that it belongs to.        It is not clearly defined in current network-based VPN models, how security associations, user authentication and ingress filtering is performed of an extranet end station trying to reach a resource or a workgroup member from another partner company.        The extranet VPN does not take into account the primary access network available to companies, namely their own campus networks. It is natural to think that partner companies will visit each other's sites quite frequently and would therefore like to have the same extranet VPN workgroup access policy apply also internally in the campus network.        
This brings us naturally to the question on how workgroups can be applied in campus networks. The current best practice in campus network design is denoted the multilayer model. The multilayer model is designed to encompass the increased usage of central server farms. The traffic pattern in this model is based on having 20 percent of the traffic local to the workgroup LAN and 80 percent of the traffic leaving the workgroup (primarily towards the server farm).
The multilayer model consists of an access, distribution, core and core distribution layer. The access layer is typically based on layer 2 Ethernet switches, each hosting a number of virtual LANs (VLANs). Each virtual LAN is restricted to about 30 employees in order to limit broadcast radiation and broadcast interrupts on end-stations. A typical access layer switch (also called closet node) can host several VLANs, but is often limited to max 100 users. This typically covers one floor in a building. The capacity of today's Ethernet switches is really much higher than the aggregate throughput requirements of 100 users. The reason to limit the number of users to about 100 is primarily related to the impact an access node failure would have on the company as whole or its employees' productivity to be more exact.
The distribution nodes are multilayer switches (layer 2 and 3). Each access layer switch is interconnected to two distribution nodes in order to provide redundancy in case of link failure. As the normal Spanning Tree Protocol (STP) has slow convergence (about 40–50 seconds), most vendors have introduced own schemes (like the UplinkFast feature in Cisco's Catalyst 5000) in order to shorten the VLAN failover time to something like a few seconds. The UplinkFast feature is only applied between two neighbor distribution nodes and is, therefore, not applicable for network-wide redundancy solution. If a switched link layer solution shall be applied for redundancy throughout the network then STP has to be used again. However, generally routing protocols have a better convergence time and are therefore preferred as the network-wide redundancy solution. As an example, OSPF is normally applied to achieve network-wide redundancy in the distribution and core layer. In a big campus network, a building constitutes an OSPF area and the distribution node becomes an area border router to the OSPF backbone. In addition, VRRP or HSRP is applied between two neighbor distribution nodes for the purpose of network layer redundancy towards an access node.
VLAN trunking of individual user VLANs is performed at the access node in order to gather all workgroup LAN access control to the distribution node. VLAN trunking may use an Ethernet Channel (multiple FastEthernet) or a GigEthernet link. The identification in the Access Control List (ACL) is based on VLAN port and MAC address.
The core network can either be based on layer 2 or “vanilla” layer 3 switching. The decision on what to choose is determined by the size of the OSPF backbone. The number of neighbors cannot be more than roughly 100 in current OSPF implementations. There may also be other considerations for segmenting the backbone into several VLANs, e.g. in order to separate management traffic from, RTP services, from HTTP services and so on.
Finally, a new set of distribution nodes are typically placed in front of the server farm and the WAN firewall DMZ respectively. All the server-to-server traffic is then kept off the backbone and VRRP can run in-between a core distribution pair for the purpose of failover protection. The core distribution nodes may also include access control lists.
Each pair of communicating distribution nodes has multiple equal-cost paths to each other. A campus IT-administrator ensures loadbalancing and redundancy from one distribution node to another across the core by running OSPF across these multiple equal-cost paths.
Current workgroup definitions in a campus network are based on the allocation of employees and their MAC addresses into virtual LANs. The user is tied to a LAN workgroup through the port number to which his MAC address is associated. The security restrictions are enforced using Access Control Lists (ACLs) on the distribution node interface towards the access layer.
A campus-wide VLAN model provides the flexibility to have statically configured end stations move to a different floor or building within the campus. When a user plugs-in his PC in a LAN port in another building, the local distribution node will send a query to a VLAN membership policy server to determine access policy and VLAN membership for the user. Then the distribution node adds the user's port to the appropriate VLAN. At the network layer, however, the end station is still required to get a new IP address that conforms to the route aggregation hierarchy of OSPF. This in turn will require the user to restart his session-based applications when changing floor or building.
Furthermore, an access control policy, that is limited to the case of Ethernet link connectivity between the end station and the distribution node, is not generally applicable. It is, e.g., not possible to apply in the case of accessing the Intranet from wide area networks (PPP or IPSec remote access) or via adhoc networks (like Bluetooth). A workgroup policy system based on network layer identities is on the other hand applicable to these cases as well
The success factors of extranets in campus networks lie in the provisioning of flexible access to and partial inclusion of personnel and servers in workgroups. This means that:                Persons that shall be part of an extranet workgroup shall be possible to select down to the granularity of individuals;        Server resources from all partners shall be possible to bring into the extranet workgroup; and        Extranet workgroup participants shall be able to roam at both, or better any, corporate location while still being granted secure access to the resources and being reachable for other colleagues.        
This means that extranet access shall be granted to members both from within the campus and from remote. One special case of the latter is when visiting one of the extranet partner's sites, at which time the workgroup member shall have access to both local and home resources allocated to the extranet workgroup.
So how does the multilayer model map to these requirements? The separation of the access layer from the server farm is a first step. However, the VLAN workgroup access control in the distribution layer is limited to the employees of the company. For extranets, there is a need for a policy management system that controls network resource usage in multiple companies. Furthermore, it is not likely that such an extranet management system will have a hook to every node in the distribution layer, but rather to specialized nodes at the DMZ. The distribution nodes will then need to be instructed to securely tunnel traffic to and from the visiting member up to a gateway node for authentication, filtering and selective tunneling back to the member's home office.
The closest resemblance of a gateway node like this is today's VPN routers. The VPN router can either apply IPSec and/or L2TP tunneling to another site. L2TP has the limitation of requiring link layer access between the end station and the L2TP Access Concentrator (LAC). IPsec is more generally applicable as it can encapsulate IP packets even in multihop access environments, as is the case in the campus environment.
IPSec-based VPN boxes may be instructed to route some traffic locally and other traffic through an IPSec tunnel to another site. Some of them are also equipped with good firewall functionality that is controlled from a central server. What they are lacking in terms of extranet support are:                A management system that helps to decentralize management of extranet workgroups to the involved parties and individuals;        A secure protocol that allows the local VPN gateway to request from the home VPN gateway authentication data on the mobile user and instructions on how to filter and route traffic based on destination and service type;        A dynamic protocol that allows a VPN box to regularly authenticate the guest user to IP address mapping in a non-“service disruptive” fashion; and        A NAT-function that can cope with overlapping address realms between members of the extranet, i.e. still providing a unique identity for reachability and filtering purposes.        
The following references are also of general interest for the understanding of the present invention:
Bellur, Bhargav et al; Topology Broadcast based on Reverse-Path Forwarding (TBRPF); http://www.ietf.org/internet-drafts/draft-ietf-manet-tbrpf-00.txt; Jul. 2000
Calhoun, Pat et al; DIAMETER Base Protocol; http://www.ietf.org/internet-drafts/draft-calhoun-diameter-17.txt and http://www.diameter.org/; September 2000
Calhoun, Pat et al; DIAMETER Mobile IP Extensions; http://www.ietf.org/internet-drafts/draft-calhoun-diameter-mobileip-11.txt; September 2000
Calhoun, Pat et al; Mobile IP Network Access Identifier Extension for IPv4; RFC2794; http://www.ietf.org/rfc/rfc2002.txt; March 2000
Corson S. et al; Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations; RFC2501; http://www.ietf.org/rfc/rfc2501.txt; January 1999
Harkins, D. et al; The Internet Key Exchange (IKE); RFC2409; http://www.ietf.org/rfc/rfc2409.txt; November 1998
Kent, S. et al; Security Architecture for the Internet Protocol; RFC2401; http://www.ietf.org/rfc/rfc2401.txt; November 1998
Kent, S. et al; IP Encapsulating Security Payload (ESP); RFC2406; http://www.ietf.org/rfc/rfc2406.txt; November 1998
Kent, S. et al; IP Authentication Header; RFC2402; http://www.ietf.org/rfc/rfc2402.txt; November 1998
Knight, S et al; Virtual Router Redundancy Protocol; RFC2338; ftp://ftp.isi.edu/in-notes/rfc2338.txt; April 1998
Montenegro, G.; Reverse Tunneling for Mobile IP; RFC2344; http://www.ietf.org/rfc/rfc2344.txt; May 1998
Perkins, Charlie; IP Mobility Support; RFC2002; http://www.ietf.org/rfc/rfc2002.txt; October 1996
Perkins, Charlie et al; Ad hoc On-demand Distance Vector (AODV) Routing; http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-06.txt; July 2000